String.match returns string[] | null; lib.ts compiles under strict null - #98

The last two items left out of #96.

What

• String.match returns string[] | null, in lib.ts (the __String function and the String class method) and in lib.d.ts. It returned null through a result declared string[].
• // @strict-null false is removed from lib.ts, so the library itself now compiles under the strict null check.

Behaviour

• What match returns at run time is unchanged: null when a pattern without the g flag does not match, and an empty array when a global one finds nothing. That second case differs from JavaScript, which gives null there too; it is kept so a global match can always be walked or counted.
• Compile-time change: a caller that used the result without a null check no longer compiles (for example <string>found or found.length). if (match) { ... } still compiles unchanged.

What the stricter compile needed

• The compiler rejected the null passed to three C functions. Their parameters are now declared nullable in lib.native.d.ts: the end pointer of strtol and strtod, and the results argument and the result of regexp_exec.
• -mm=own rejected return [...result] with the new return type ("a second reference"), so match puts the array in a local first, as matchAll does before its yield.

The searchString == null guards in the string helpers stay: they compile under strict null and still catch a null string from a caller.

Testing

• tests/string_match.ts and tests/string_match_lastIndex.ts check for null before using the result, and string_match.ts asserts null for no match without g and an empty array with it.
• Release, Windows x64: the whole suite passes for gc, rc, none and own, compiled and under the JIT.
• scripts/check_declarations.ps1 passes.
• Not run locally: debug builds, Linux, x86 and wasm. lib.linux.ts and lib.wasm.ts are now compiled under strict null as well; the only literal null in them is in a declaration that is already nullable.

🤖 Generated with Claude Code